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Abstract 

Turbine engines are highly complex mechanical systems 
that are becoming increasingly dependent on control technol- 
ogies to achieve system performance and safety metrics. 
However, the contribution of controls to these measurable 
system objectives is difficult to quantify due to a lack of tools 
capable of informing the decision makers. This shortcoming 
hinders technology insertion in the engine design process. 
NASA Glenn Research Center is developing a Hardware-in- 
the-Loop (HIL) platform and analysis tool set that will serve 
as a focal point for new control technologies, especially those 
related to the hardware development and integration of distrib- 
uted engine control. The HIL platform is intended to enable 
rapid and detailed evaluation of new engine control applica- 
tions, from conceptual design through hardware development, 
in order to quantify their impact on engine systems. This paper 
discusses the complex interactions of the control system, within 
the context of the larger engine system, and how new control 
technologies are changing that paradigm. The conceptual 
design of the new HIL platform is then described as a primary 
tool to address those interactions and how it will help feed the 
insertion of new technologies into future engine systems. 

Introduction 

Turbine engines are correctly viewed as complex mechani- 
cal systems comprised of a set of specific and highly opti- 
mized components. From the fan to the nozzle, the explicit 
purpose of each component has remained unchanged over 
time. The design of these components is also highly special- 
ized; dominated by the innovations of highly skilled individu- 
als, sophisticated tools, and a multitude of technologies 
seeking the optimization of each device. The result is that the 
contribution from each component to the overall operation of 
the engine is well understood. 

When completely assembled and viewed as an engine sys- 
tem, however, the limitations and weaknesses of each mechan- 
ical component become more apparent. Therein lies the 
purpose of the control system; to enable the sustained optimum 
performance, safety, and stability of the entire engine system 
across its full mission profile and lifespan. 

The control system is also an engine component. Unlike its 
mechanical counterparts, however, the control system has 
drastically morphed over time, having transformed its imple- 
mentation from the mechanical to present day computerized 
technologies (Ref. 1). In functional terms, its role has vastly 


expanded from simple speed control to a broad array of capa- 
bilities designed to maximize performance as well as alleviate 
pilot burden and extract maximum useful life from the engine’s 
mechanical parts. 

As an engine subsystem, controls are both highly specialized 
and ubiquitous, having to interact with virtually every engine 
component. The control system operates both locally and glob- 
ally across the engine system, yet the contributions of control 
hardware and software are difficult to analyze in terms of their 
individual impact on the system performance. Consequently, 
these contributions are often excluded from the multidiscipli- 
nary design and optimization (MDAO) process, which has 
become the predominant methodology driving design decisions 
on turbine engine systems (Ref. 2). The lack of tools that can 
help quantify the contributions of controls also impedes new 
research and development and, ultimately, the adoption of new 
control technologies on production engines. Subsequently, 
control design in practice is often regarded as a mysterious, 
trailing-edge step in the turbine engine design process. 

Future engine systems will require the presence of far more 
control capability to implement the suite of advanced technol- 
ogies now in the pipeline (Refs. 3 to 5). Anticipating this need, 
better techniques and tools will be required in the development 
of next generation systems. The key will be to work more 
cohesively during the early development of individual turbine 
components rather than for controls to remain primarily in the 
role of system integrator after the major design decisions have 
been made. 

The expanded use of modeling and simulation will be a key 
element in this process. One of the first steps in the design of 
every modem engine is to create detailed numerical models of 
engine components. These models necessarily emphasize abso- 
lute accuracy. However, this type of modeling is typically not 
suited for controls development because it fails to adequately 
replicate system dynamics, or at least requires enormous resources 
to do so. While a mechanical engine system can be relied upon 
to perform at any valid operating point, it is an explicit purpose 
of the control system to safely bridge the transition between 
those conditions. So the requirement for modeling in the controls 
domain is an accurate replication of the dynamics of the system 
with possible compensation for the steady state. It is also highly 
desirable that such models be capable of mnning at least in real- 
time, whether the modeling is for an on-board application, 
ground application, or development purposes. In fact, when 
hardware is involved, real-time is a requirement. This is typically 
accomplished using piece-wise linear representations obtained 
from higher order models (Ref. 6). 
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The development of Hardware-in-the-Loop (HIL) systems 
is a natural follow on to these modeling activities as they 
afford the opportunity for low cost testing of control hardware 
against a realistic simulation of the expected environment. 
The automotive industry is far advanced in this area, having 
demonstrated HIL to not only develop control hardware but to 
evaluate the efficacy of new technologies (Refs. 7 and 8). 
There are a number of other HIL examples in industrial con- 
trol networks (Ref. 9), flight control (Ref. 10), and even tar- 
geted applications on turbine engines (Ref. 11). 

It is clear that new technologies are rapidly changing prod- 
ucts in many industries, not just engine control. This is espe- 
cially true as electronics and controls become more 
distributed and embedded in the components of complex 
systems. Less apparent is how these technologies are affect- 
ing the product development processes, the supply chain, and 
even the capabilities of manufacturing organizations them- 
selves (Ref. 12). 

In 2009, the Distributed Engine Control Working Group 
(DECWG) put together a cooperative demonstration of con- 
trol system integration at the American Institute of Aero- 
nautics and Astronautics Joint Propulsion Conference in 
Denver, Colorado (Fig. 1). Network enabled control compo- 
nents representative of distributed engine control sensors, 
actuators, and subsystems were quickly developed by 12 


separate companies in a timeframe of about two months. Most 
of the integration occurred remotely by teleconference simply 
because it only involved establishing a well-defined interface 
consisting of power and communications protocol. The full 
physical integration actually occurred at the conference exhibit. 
Its success was in demonstrating that separate organizations, in 
fact, competitors, could collaborate in the development of a 
common controls technology. 

This event actually spurred a renewed interest in the cooper- 
ative precompetitive development of distributed control tech- 
nologies among government, industry and academia that exists 
to this day. In this community, it is widely recognized that the 
development of distributed engine control is beyond the reach 
of any individual organization. Without cooperation and the 
leveraging of technology development investments, distributed 
engine control components would be novelties, i.e., they could 
not exist on the scale necessary to incorporate in production 
turbine engines. 

NASA Glenn Research Center views tool development as 
one of the main contributions they can make to distributed 
engine control technology. A new Hardware-in-the-Loop plat- 
form is therefore being implemented with the intention of using 
it to develop and communicate the benefits of new technolo- 
gies as they apply to turbine engine control; a capability needed 
across industry. 



Figure 1. — Working demonstration of the integration of distributed engine control components at the 2009 
AIAA Joint Propulsion Conference. Twelve companies participated in providing “smart” networked sensors 
and actuators in a conceptual architecture. 
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This paper will discuss the changing environment for engine 
control architecture, a topic relevant to current propulsion 
research at NASA, and explain how HIL can become a focal 
point and pathway for the integration of engine control technolo- 
gies. The paper begins with a discussion of the interaction 
between the engine system and controls and how this interac- 
tion occurs on multiple levels that are not always readily 
apparent. Next, a description will be offered as to how new 
distributed control technologies are altering this paradigm and 
the effect it will have on how organizations interact with each 
other. Finally, a discussion will be provided that outlines the 
development of NASA’s new Hardware-in-the-Loop platform 
and its potential to extend collaboration between organiza- 
tions in the development of new turbine engine capabilities. 

Engine System — Control System 
Interactions 

When a complex system is designed, it is natural to try to 
establish an organizational framework around the system. The 
organization provides a methodical approach that allows 
several less complex problems to be worked in parallel. This 
structure extends not only to the physical design of the sys- 
tem, but often to the way organizational resources are allo- 
cated. Although the intent of the structure is to solve the 
design problem efficiently, it can also create walls that pre- 
vent the insertion of new ideas. This is especially true when 
technical knowledge is imperfectly shared between groups. 

The turbine engine is comprised of a fan, compressor, com- 
combustor, turbine, etc. These subsystems, or components, 
provide the natural delineations that define the traditional 
organizational framework for the turbine engine system. The 
interface between these adjacent components defines all 
interaction and can be identified by the set of inputs and out- 
puts for each subsystem. Adequately defining and under- 
standing these interfaces is critical to the overall engine 
design. How well this process is accomplished becomes 
apparent when the subsystems are integrated. 

The control system is an unusual engine component due to 
the fact that there are interfaces, and therefore interactions, 
between it and every other component. Some of these inter- 
faces are through the direct physical contact of the sensors 
and actuators. Some interfaces are virtual; that is, the opera- 
tion of a component can be indirectly altered when the control 
logic attempts to optimize the entire engine system. Still other 
interfaces are even less apparent to control and engine func- 
tion, such as the structural mounting of hardware and the 
routing of wiring harnesses. The implication is that control 
system interfaces are very complex; they occur on multiple 
levels of abstraction, and are therefore difficult to clearly and 
completely allocate to individual engine components. 

Nevertheless, it is always true that components on either 
side of an interface affect one another because the interface 


requires both a definition of requirements and an imposition of 
constraints (Ref. 13). 

Today, turbine engine control is generally implemented 
through a Full Authority Digital Engine Control (FADEC) with 
an integral electrical power system, and a suite of sensors and 
actuators specific to that engine. The control system hardware 
is fully integrated with the mechanical engine system, making 
the engine functionally independent of the airframe. Operating 
the engine requires interaction over a relatively simple inter- 
face that primarily includes a throttle command and a fuel 
source. This engine -airframe interface tacitly acknowledges an 
organizational boundary between different manufacturers. 

Traditionally, the FADEC, or engine controller, has many 
specific interfaces that exist as dedicated physical connections 
to hardware control elements scattered throughout the engine 
system. Some of these are shown in Figure 2. Internally, the 
FADEC is essentially a digital computer with a substantial 
number of I/O channels ported off a common internal data bus. 
The software application code is often accompanied by hard- 
ware logic for redundancy of critical control elements. The 
design of the FADEC hardware and software, a subsystem of 
the control system, is therefore dependent on the design of the 
entire control system. It also follows that the larger control 
system design, a subsystem of the engine system, is dependent 
on the design of the entire engine system. Control engineers are 
often heavily invested with closing out the engine system 
design process under severe cost and schedule constraints 
because they are at the tail end of the critical path. This 
approach leaves little room for new technology insertion in the 
control system. 

Fortunately, the control system can be visualized from a dif- 
ferent perspective. In a virtual sense, the control system is 
simply a set of algorithms that operate on input data to provide 
output commands that control the operation of the engine. In 
this abstraction, control occurs strictly through the processing 
of algorithms that define the engine operation. There is no 
hardware definition or location dependence for processing in 
this view. The real requirement is the timeliness and accuracy 
of the data flow connecting functional elements of the control 
system. 

Designing the control system from a functional perspective 
rather than beginning with a preconceived hardware configura- 
tion, like the current FADEC, leads to a more flexible concep- 
tualization of the control architecture. The decomposition of 
control functions into elemental constructs is fundamental to 
the systems engineering process. These primary elements can 
then be arbitrarily reconstituted into flexible and modular 
blocks representing various system architectures. The design 
decisions regarding how to assemble these blocks can, and 
should, take into account all aspects of the system design, 
especially how constraints are allocated among the various 
control blocks. In this way, constraints can become a system 
variable instead of a fixed parameter. 
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Figure 2. — A typical engine control system is shown. The centralized engine control unit, or FADEC, has many discrete 
analog interfaces that are specific for each control element. The controller also has interfaces that integrate the engine 
control into the airframe. 


Control System — Impact of Control 
Architecture 

As previously mentioned, organizational and technological 
issues strongly affect how complex problems are solved. Con- 
trol system design is no exception. However, the barriers pre- 
sented by organizational concerns seem to persist for longer 
periods, even after technical solutions offer new opportunities 
for progress. These barriers are likely due to imperfect 
knowledge in an organization and a natural aversion to risk. 
The limited progress in advancing engine control technologies 
is often an example of an organizational barrier at work. 

All control systems have basic elements consisting of sen- 
sors, controller, and actuators. For obvious reasons, the func- 
tions of sensing and actuation are restricted to specific physical 
locations on an engine; you can’t sense something without a 
sensor or move a control surface without an actuator. This 
limits the degree of design freedom in placing controls. 

In addition, most control hardware is also strongly affected 
by environmental factors that result from the normal operation 


of the engine. This is a consequence of an underlying depend- 
ence on electronics, which are especially affected by tempera- 
ture. Minimizing the number of heavy enclosures to protect 
electronics usually results in minimizing the overall cost function 
of the engine design. Preferably, these enclosures are situated in a 
relatively cold location on the engine, typically the fan casing, 
as shown in Figure 3. The aggregation of electronics in central- 
ized enclosures leads to a centralized control architecture, 
resulting in a FADEC with complex interfaces that are typically 
expressed externally as an equally complex web of wiring 
harnesses. Adjusting the location of any control element, espe- 
cially the FADEC, is not trivial. Still, it is relatively easy to 
visualize an item being moved around the engine envelope 
while dragging its interface cables around with it. 

Moving a centralized FADEC to a new location on the engine 
typically does little to alter its functionality. Nevertheless, the 
move can have a substantial impact on engine system weight 
(changes in harness length), maintenance (accessibility of con- 
trol elements), and ancillary support systems (heat removal), etc. 

One of the major technical barriers underlying distributed 
control is the need to overcome the environmental constraints 
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Figure 3. — The engine control unit (ECU), or FADEC, is 
shown mounted on the casing of a high bypass turbine 
engine, illustrating the size and complexity of the control 
system hardware and interfaces. Public release photo 
courtesy of Pratt & Whitney. 


on control electronics. This is not a constraint on control itself 
but on the fundamental technology underlying control com- 
ponents. Consequently, these constraints exist regardless of 
the control implementation approach used on the engine. 
However, sufficiently raising the operational temperature for 
control electronics allows the physical implementation of 
control functions to more easily replicate any of the arbitrary 
control schemes that can be envisioned through the system 
engineering process previously described. This includes local 
control intelligence and digital communication capability 
embedded in each control element. High temperature elec- 
tronics clearly enables more distributed engine control, 
assuming the absence of other barriers, like cost. 

Once the primary barriers to distributed control are 
removed, the physical elements of the distributed control 
system can be included and evaluated at the engine compo- 
nent level during component design. Interface complexities 
and design dependencies between control elements largely 
disappear because they communicate over a digital network. 
Control system integration becomes a much simplified task 
involving data flow analysis between control elements, which 
can be accomplished very early in the design process. The 
fundamental control problem at the time of engine system 
integration then becomes “how to integrate the control sys- 
tem ” instead of the original problem, which was “how does 
control integrate with the engine system .” The “cost” of con- 
trol, and by default the benefit, becomes a quantifiable part of 
the design process instead of a constraint on the end product. 
This shift in approach opens up the possibility of simplifying 
the evaluation of new technology insertion at an earlier stage 
of development. 

Just as high temperature electronics fundamentally alters 
control integration, distributed control fundamentally alters 
engine system integration. Consider the case of an engine 
sensor such as Ps3, the static pressure sensor at the exit of the 


compressor. The Ps3 sensor signal is used in the engine con- 
troller for a variety of reasons that include calculating overall 
pressure ratio, specific fuel consumption and thrust estimation, 
and as a limiting value for compressor operation. For the pur- 
pose of control, the signal from the sensor simply becomes an 
input value used in processing the control laws. 

In a typical physical implementation of centralized engine 
control, the Ps3 sensor (static pressure at the exit of the high 
pressure compressor) is housed in the environmentally con- 
trolled FADEC enclosure and connected by a long pneumatic 
tube to the casing wall at the high compressor exit. The sensor 
is supplied by the FADEC with whatever electrical power it 
requires. Meanwhile, the sensor output signal is filtered, ampli- 
fied and digitized as one of many I/O channels. From there, the 
signal is made available to the FADEC for any additional sig- 
nal processing prior to use in the control logic. 

The distributed control implementation, in contrast, would 
package the Ps3 sensor, power conditioning, signal condition- 
ing and digitization together at the high pressure compressor 
casing in a “smart” sensor module. Included in the package 
would be the electronics for communicating the Ps3 data over a 
digital network. These differences in implementation are 
shown in Figure 4. 

The system impact of this change is profound, if not readily 
apparent. At the compressor, the simple pneumatic penetration 
is replaced with the sensor module containing the volume and 
mass of the transducer and associated electronics. The physical 
complexity is locally increased at the compressor, but the 
packaging constraints are not as rigid as when Ps3 was one of 



FADEC 


SW 

=C= 


Processor/Memory 




Smart Sensor b) 


Figure 4. — Implementation examples for obtaining Ps3 data; 
(a) Centralized architecture with multiple channels of I/O 
in the FADEC; (b) Distributed architecture with an all- 
digital FADEC and external “smart” devices connected 
by a digital network. SW = software control applications, 
A/D = analog-to-digital conversion, F = filter, SC = signal 
conditioning, PT = pressure transducer, pC = microcontroller, 
P = Physical Process being sensed. 
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many collocated I/O inside one FADEC enclosure. Instead of 
using a rigid pneumatic tube, the pressure signal and electric 
power are transmitted over a standard interface using a thin 
bundle of wires. In the case of the distributed FADEC, all 
the dedicated, analog I/O electronics have been removed and 
replaced with an interface for multi-drop communications. 
The volume, mass, and complexity of the new FADEC is 
therefore substantially reduced. 

In the new paradigm, the control “function” of producing 
Ps3 data is wholly contained in one component located on the 
engine casing. Meanwhile, the FADEC is now entirely digital 
and is no longer constrained by a multitude of physical inter- 
faces and the weight of associated cables. Since the FADEC 
is no longer dependent on the I/O configuration, its physical 
design is largely independent of changes in the engine con- 
figuration, including changes to the number, configuration, 
and function of sensors and actuators. Perhaps most dramati- 
cally, the FADEC box could even be located off-engine for 
additional weight reduction. 

From a systems perspective, the Ps3 smart sensor module 
can be “owned” by the compressor component designers who 
would specify its entire function. The specification can be 
released to a pool of suppliers that would manufacture it as a 
device to be plugged into the control system. The functionality 
of the module could even be expanded by design, or as a value- 
added feature, without significantly impacting the engine con- 
troller hardware design. For example, temperature measure- 
ment or compressor stability detection could be incorporated 
into the same smart device. 

Distributed control has the capability to change the design 
and development processes of the entire turbine engine. This 
one example served to illustrate the complex interactions 
between the engine manufacturer, system integrator, supplier 
and air framer, which were all affected. Due to the control 
system’s prominent role in the integration of the engine sys- 
tem, it is very likely that a change in control architecture to 
distributed control will create changes in each of these organ- 
izations as well. 

Hardware in the Loop System 

The NASA Hardware-in-the-Loop system is a research tool 
primarily intended to develop and demonstrate distributed 
control technologies. It is also being developed as a non- 
proprietary system tool to promote collaboration across the 
controls community. There is potential to eventually create a 
seamless platform that can bridge the processes from control 
system design through hardware development, integration 
activities, and even into system verification. The initial goal is 
to create a scalable system that can be made available to users 
who will implement as much or as little of the real-time hard- 
ware capability as they require. As an open-ended development 


tool, HIL can proceed in stages. The approach is to integrate a 
variety of design and analysis tools into HIL to assist the unre- 
stricted exploration of turbine engine control technologies. 

The HIL system, as currently envisioned, has three distinct 
parts: an Engine Plant Model (EPM), a real-time Control Sys- 
tem Platform (CSP), and the User Interface (UI), as shown in 
Figure 5. The purpose of the EPM is to provide accurate stimu- 
lation to the control system sensors while realistically respond- 
ing to control system commands. The EPM will also be 
responsive to signals representative of ambient condition inputs 
as it processes mission profiles in the simulated environment. 
The purpose of the CSP is to provide a platform that allows 
users to easily design, develop, and execute models of the 
control system, including individual distributed control com- 
ponents. If desired, these control component models can be 
transitioned to hardware, eventually replacing the simulated 
model in the CSP. In addition to the sensor and actuator inter- 
faces with the EPM, the CSP will interface to signals repre- 
sentative of the airframe and cockpit controls as was previously 
shown in Figure 2. Lastly, the UI will interact with both the 
EPM and the CSP. Operationally, the UI will provide the capa- 
bility to control the simulated engine, through the control sys- 
tem, in a manner representative of the engine-airframe 
interface. As a research tool, the UI will also allow deeper 
interrogation and manipulation of EPM and CSP variables to 
gain fundamental understanding of performance characteristics 
while also having the ability to introduce anomalies. 

Like distributed control, the HIL is organized as a modular 
system and is dependent on the interfaces between its compo- 
nents. These are described in some detail below. 



Figure 5. — The functional interfaces of the control system are 
all rigidly defined to strictly replicate the type of information 
that flows between the engine and control system. However, 
the User Interface (UI) is also able to perform deep interro- 
gation of both the engine and control simulations. 
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Engine Plant Model 

HIL system development begins by leveraging the NASA 
Glenn software known as C-MAPSS40k, which is repre- 
sentatively shown in Figure 6. C-MAPSS40k is a realistic 
0-D simulation (a non-linear model lacking radial and axial 
detail), representative of a 40-thousand pound thrust class 
turbine engine. It includes the accurate engine dynamics that 
are necessary for controls development. It runs under 
MATLAB/Simulink (MathWorks, Inc.) and is capable of 
much faster than real-time execution in a common PC plat- 
form. This software is available to U.S. citizens only. 

The existing C-MAPSS40k software is very modular in 
design in order to accommodate user modifications to indi- 
vidual engine components. The code also incorporates basic 
controller algorithms that allow engineers to evaluate engine 
performance under various conditions. As a first step, the 
EPM in C-MAPSS40k will be isolated from the control sys- 
tem, the ambient environment, and the airframe. Interfaces 
between these components are defined in such a way that they 
replicate the flow of data across the physical boundaries of an 
engine and its control system and are therefore accessible to 
the user as they would be in the physical system. The goal is 
to isolate the EPM and create a common interface definition 
and methodology that defines how users interact with the 
engine. Eventually, this format is expected to enable engine 
plant simulations from other sources to be inserted into the 
HIL system in place of the non-proprietary C-MAPSS40k. 
This feature will be useful to users of the HIL tool for their 
proprietary models. 

All of the calculated variables of the engine plant are classi- 
fied as engine plant outputs and will be accessible as digital 
values in engineering units, if applicable. All of this infor- 
mation will be available to the UI. A subset of these EPM 



Figure 6. — Diagram of the C-MAPSS40k engine simulation 
which will form the basis of the Engine Plant Model to be 
used in the development of the HIL. The model provides 
the realistic engine dynamics necessary for controls 
development and it can run in real-time or faster. 


output values represent sensed parameters and these will be 
made available to the control system as sensor input values. 

Input variables to the EPM will likewise be in engineering 
units. Those values that represent actuator outputs will origi- 
nate from the control system. The remaining EPM inputs will 
be provided by the UI and will represent quantities that origi- 
nate from one of three sources: simulated ambient operating 
conditions, the simulated airframe, or user-determined engine 
health parameters. These health parameters are intended to 
provide the user with the capability to test the operability of a 
degraded engine. 

The interface definition surrounding the EPM is of special 
significance, assuming HIL has the capability to “drop in” 
other EPMs. One set of issues regards intellectual property 
while a second regards the complexity of the interface. 
Accommodating these collaborative user concerns in the HIL 
design is explained below. 

EPMs represent a very significant investment in an engine 
company’s intellectual property that must be adequately pro- 
tected. It is likely that these models will at least need to be pro- 
vided as an executable or use some other method of obscuring 
the source code. In addition, legacy engine models may exist that 
have been developed outside of the MATLAB/Simulink envi- 
ronment. Instead of disclosing or recoding these models, a pro- 
cess for integrating them into the HIL environment will need to 
be developed. In either case, it would be unusual for an organiza- 
tion to allow such valuable information to be held in the control 
of another party. 

The issue of complexity arises in the form of how the engine 
model interfaces with the rest of the HIL system, especially 
when control hardware is involved. Keeping the complexity of 
physical control hardware isolated from the EPM simplifies 
this interface. The EPM must produce the data that a hardware 
control sensor eventually senses and it must accommodate the 
actual response of a hardware control actuator. However, it 
does not have to be involved in creating the physical analog of 
these interfaces. This complexity will be discussed in the sec- 
tion on the CSP. 

There are advantages to running engine models and control 
models on the same hardware platform. However, maximum 
flexibility and independence is likely to be achieved by running 
them on separate machines connected by a high speed data 
interface. Both options may likely need to be accommodated. 

Control System Platform 

The Hardware-in-the-Loop test bed is primarily intended for 
the development of control technology as it relates to distributed 
control. This is a fundamentally different problem than what is 
encountered in test beds for centralized control architectures 
due to the nature of the control interfaces. 

The controller stripped out of C-MAPSS40k does not reflect 
any of the detail of control hardware since it operates at a high 
level of abstraction. However, research in distributed control is 
intended to further the understanding of how the hardware 
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configuration affects the performance of both the control 
system and the engine system. This includes a better under- 
standing of system constraints, which can play a huge role in 
determining whether technology is adopted. While perfor- 
mance can include such things as transient response and sta- 
bility, constraints may involve a wide array of parameters like 
weight, reliability, fault isolation, and cost. A detailed under- 
standing of the control system components and interfaces is 
required to accomplish this task. 

The first step in development of the CSP will be to create a 
library of elemental control functions in simulation. These 
can be used as modular blocks to build any type of control 
system component including sensors, actuators, data concen- 
trators, loop closure elements, complex subsystems, etc. Over 
time, it is expected that control system element models will 
be provided by many sources, including actual production 
suppliers of control components. 

Control component models, once assembled, can then be 
connected in simulation using various system configurations 
representative of a control architecture. In a distributed con- 
trol system, the interconnection of control elements occurs 
through a digital network. However, the network is another 
example of a control system component. It too must be modu- 
lar in nature so that it can be upgraded or replaced as technol- 
ogy improves. 

As in the EPM, control system interfaces will be rigorously 
enforced. All communication between the EPM and the CSP 
will be through sensors and actuators. Any data that would 
normally pass between the control system and the airframe, 
such as throttle position, will originate at the UI; however, 
those signals should use the appropriate control system inter- 
faces designed for that purpose. Of course, the CSP will pro- 
duce and use other data in its internal calculations, which will 
also be visible at the UI, when operating in simulation mode. 
Such data include parameters like system health, which gov- 
ern faults or degradation. Once control hardware is inserted in 
the system, however, the component interface may preclude 
such information from being accessible to the UI. In other 
words, it is possible to deeply interrogate a computer model 
of a component, but it is not so easily accomplished when that 
component exists in hardware form. These interfaces are 
shown in Figure 7. 

Network communication is a component of distributed con- 
trol that serves the critical function of gluing the control 
modules together into a cohesive system (Refs. 14 and 15). 
One or more control networks, of different types, can poten- 
tially exist in any given control architecture. These control 
networks are expected to impact system stability and reliabil- 
ity as they introduce sources of delay, noise, and data loss. 
Engine network technology is intimately linked to the capa- 
bility of high temperature electronics and may change rapidly. 

In these distributed systems, it is the network that primarily 
defines the interface between components. Using interface- 
based design (Refs. 16 and 17), it is possible to allocate 
system functionality in a variety of network connected archi- 
tectures. Analyzing the data flow between these elements can 


reveal the overall system performance as well as define the 
individual functional performance of each connected control 
element. By strictly conforming to these interface definitions, 
any simulated component can be replaced by its hardware 
equivalent in a manner that is transparent to system operation. 

It must be pointed out that the time base in which all EPMs, 
control system models, and control hardware operate under 
must be consistent. They do not necessarily have to be syn- 
chronized, but the unit of time must be consistent in all com- 
ponents in order for their interactions to be properly evaluated. 
When control hardware is involved, real time is the only possi- 
ble time base; otherwise simulations can occur faster than real 
time. 

Other complexities also arise with control hardware. A hard- 
ware control sensor is designed to convert a physical parameter, 
like pressure, speed, or temperature originating from the engine, 
into an electronic signal. Likewise, a hardware control actuator is 
designed to convert an electronic command into a physical 
action. In simulation, this is not a problem because there are only 
digital data originating or terminating at the EPM. When hard- 
ware is involved, the physical nature of the control devices must 
be confronted. 

One method of dealing with hardware control actuators is to 
run the hardware open-loop, but in parallel with an instance of 
the actuator model that feeds digital data into the EPM input. 
An alternate method is to construct a specialized apparatus to 
properly load and measure the action of the hardware actuator, 
converting the physical parameter into data for the EPM input. 
This apparatus is depicted in Figure 7 as the analog subsystem. 
This latter method runs the risk of introducing dynamics into 
the actuator response that may not exist in an actual application. 



Figure 7. — The Control System Platform (CSP) consists of a 
real-time computer running control element models and an 
analog subsystem to accommodate the physical interfaces 
of control hardware. All interfaces attempt to mimic those of 
a real engine system. 
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For hardware sensors there is typically no convenient way 
to bypass the need for a specialized analog interface in which 
to stimulate the sensor. However, in some instances, it may be 
acceptable to use an electrical analog of the signal instead of a 
physical analog. This can be accomplished by inserting the 
electrical analog signal downstream of the transducer inside 
of the smart sensor. Of course, this capability would need to 
be accounted for in the design of the sensor. As previously 
stated, attempting to generate the physical analog of an engine 
parameter is prone to spurious dynamics and safety issues 
unless carefully constructed. 

User Interface 

The UI will provide a means for the user to configure and 
operate a control system while examining those metrics that 
are relevant to controls and to engine system performance. 
The idea is to have an ability to quickly create, test, and eval- 
uate relevant situations that will help optimize control system 
design. This is best accomplished using a unified platform 
instead of a collection of separate component interfaces. 

The UI will interact directly with the engine (EPM) and 
control system (CSP). This basic interaction can be summa- 
rized in the following list: 

• Create a library of modular control functions 

• Use library functions to design control elements 

• Use control elements to design control architectures 

• Assign engine-input/control-output variables and 
engine-output/control-input variables 

• Operate control architectures through engine-airframe 
interfaces 

• Provide mission profile scripts for control system 
operation and the ambient environment for both engine 
and controls 

• Provide scripts to introduce engine or control system 
faults or degradation 

• Collect and archive data from the control system 

• Collect and archive data from the engine system 

• Analyze data sets 

The interaction between the engine and control system is 
limited and defined by specific interfaces that replicate the 
same interactions that occur in the physical engine system. 
However, no such restriction is necessary with the UI except 
when the UI is simulating the pilot and airframe interaction. 
In fact, the ability to visualize and manipulate all system 
information is the UI’s greatest asset. This capability can 
allow efficient data collecting, archiving, and post processing 
operations. 

The exact implementation of the UI may depend on what a 
particular user intends to accomplish with the HIL system. If 
there is no intention to use external EPMs beyond 
C-MAPSS40k, then the EPM could be integrated into the 
CSP. If there is no intention to introduce hardware into the 


HIL, then there is no need for a real-time computer in the CSP. 
The implementation of the entire HIL system, consisting of UI, 
EPM and CSP, could then feasibly exist on a single personal 
computer. However, the maximum capability of the HIL is 
achievable only by adhering to the interface definitions that 
allow the system to be easily scaled up or down. The interface 
definitions between the three components are functional inter- 
faces, if not actually physical interfaces. 

The UI will also host an additional range of tools that are 
required to thoroughly understand system constraints. 

Tool Development 

A wide variety of tools can be developed for use in the HIL 
that can evaluate more than just performance. Many of these 
tools can be associated with a stage of development, e.g., 
design, operation, or analysis, or whether the application 
involves simulation or hardware. As a non-proprietary system, 
however, these tools should be designed to be compatible with 
each other, at least to the extent that data can be shared. Ulti- 
mately, one of the end goals is to produce information that will 
allow control systems to be an integral part of the MDAO 
effort in engine design. 

The need for many tools can be drawn from the previously 
presented discussion. For example, as control elements are 
constructed in simulation it would be useful to track infor- 
mation, including estimates for reliability, weight, and cost. 
When an architecture is assembled from these elements, tabu- 
lating knowledge about these parameters would be useful in 
constructing trade studies. 

Likewise, as simulated control elements are located on the 
“physical envelope” of the simulated engine, environmental 
information extracted from the engine simulation could be used 
to develop specifications for a hardware design. Later, this 
environmental information could be used to provide a forcing 
function to test actual hardware for temperature and vibration. 

Locating control elements on an engine structure is also com- 
plicated by the routing of wiring harnesses. Having a capability 
to place these components, then automatically route cabling 
while tabulating weight and pin contacts, could be extremely 
valuable. A notional depiction of how this might interact with 
computer aided design software is shown in Figure 8. 

Automated monitoring of data flow through the control system 
is necessary in order to understand stability, transient response and 
performance. This capability will allow the requirements for indi- 
vidual components and networks to be quantified. It will highlight 
system bottlenecks, allowing the optimization of control architec- 
ture as well as the analysis of system faults and anomalies. 

There is also a need to consider the future direction of hard- 
ware and software technologies. For instance, commercial 
computing platforms are moving rapidly in the direction of 
powerful multi-core processors that provide the capability for 
concurrent as well as parallel execution of software. This capa- 
bility inherently exists in a physically distributed control sys- 
tem; however, tools to evaluate and optimize the partitioning of 
these functions across a control system are needed. Even within 


NASA/TM— 20 13-217883 


9 



the HIL simulation platform, this capability enables complex 
models to be subdivided and executed in parallel. In fact, 
each control element model in the HIL could eventually be 
assigned to its own processor. In this way, the simulation 
process could be exactly analogous to the physical implemen- 
tation of a distributed system. There are active research pro- 
jects, such as the Ptolemy Project (Ref. 18), that are 
investigating ways to take advantage of these powerful com- 
puting platforms, especially as to how they relate to real-time 
and embedded processors. 

Another aspect of distributed systems is their ability to 
accommodate new types of control hardware. The hardware 
technology of high temperature electronics occupies a rela- 
tively small but important niche. Since one of the primary 
purposes of HIL is to develop high-temperature capable 
smart control effectors, the limitations of this type of elec- 
tronics must be well understood. HIL could play a signifi- 
cant role in the development of standardized programming 
tools for embedded, high-temperature electronics software 
and firmware. 

Distributed control components will likely follow similar 
development paths whether they are physical hardware or 
simulation because they are likely to take advantage of reusa- 
ble design elements (Ref. 19). Portions of control components 
can be extracted from a standard library just as circuits are 
constructed from a catalog of electronic components. As 
individual simulated elements are constructed, they can be 
tested through their defined interfaces prior to insertion into 
the control system. This naturally leads to development of 
verification and validation technologies. 

By designing the HIL system as a flexible, scalable plat- 
form, it has the potential to bridge the control development 



Figure 8. — A notional depiction of how tools accom- 
panying the HIL platform could interact with other 
engine design processes. Here, physical placement 
of control system components on the engine enve- 
lope could be used to assess the weight of control 
architecture configurations or associate engine 
environmental characteristics to control elements. 


process from low level research through hardware develop- 
ment, including the potential to extend into the realm of control 
system verification and validation. Without such a capability 
driving the controls community toward cooperative interface 
standards development, it is likely that the integration of con- 
trol systems will continue to be a costly and time-consuming 
process. 

Summary 

A Hardware-in-the-Loop (HIL) system is being developed at 
the NASA Glenn Research Center with the intention of devel- 
oping distributed control technologies and understanding con- 
trol system constraints. The HIL is being based on the NASA 
C-MAPSS40k software, which simulates the dynamics of a 
realistic 40-thousand pound thrust class turbine engine. The 
HIL will be modular, consisting of three major components: 
the Engine Plant Model (EPM), the Control System Platform 
(CSP), and the User Interface (UI). Interfaces between the 
three subsystems are defined to closely correlate with the inter- 
faces found in actual aero-engine applications, specifically 
engine -to-control-system and control-system-to-airframe. The 
CSP will host the simulated components of a distributed con- 
trol system including simulated communication network struc- 
tures. All of these components can be assembled from a 
resident library of basic control functions and subsequently 
connected into arbitrary control architectures that can be tested 
and evaluated in the HIL. Hardware elements, potentially 
derived from initial HIL simulations, can be integrated into the 
HIL and the entire system run in real-time. Identified for inclu- 
sion in the UI will be a host of tools to aid in the design, opti- 
mization, and integration of control systems, including the 
ability to quantify system metrics and benefits that will lead to 
enhanced participation in the design of future engine systems. 
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